Synchronizing Events Between Mobile Devices and Servers

ABSTRACT

A system, method, and computer program product for synchronizing events between a mobile device and a server are described herein. In an embodiment, the method operates by detecting events to be synchronized between a source and a target, wherein the source and target are one of either a mobile device or a server. The method comprises deducing activities that occurred in order to create the detected event, reading data records corresponding to the deduced activities, and creating packets of operations needed to recreate the deduced activities on the target. The method further comprises queuing the packets of operations and data records and receiving event synchronization results at the source after the queued packets of operations have successfully executed on the target, wherein the synchronization results include a synchronization status and a unique record identifier identifying the event. In an embodiment, personal information manager (PIM) events are synchronized.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.12/432,382, filed Apr. 29, 2009, which is a continuation-in-part of U.S.application Ser. No. 12/104,905, filed Apr. 17, 2008, which claims thebenefit of U.S. Provisional Application No. 61/040,393, filed Mar. 28,2008, all of which are herein incorporated by reference in theirentireties.

FIELD OF THE INVENTION

The present invention relates generally to mobile communications and,more particularly, to synchronizing personal information manager (PIM)events, email, data, applications, business processes, and calendarupdates between mobile client devices and servers.

BACKGROUND OF THE INVENTION

Mobile devices are in common usage, many featuring powerful processors,larger and more colorful displays, and wireless networking capabilities.Despite these advances in mobile technology, mobile devices typicallyhave greater limitations on memory capacity, data storage capacity,central processing unit (CPU) capacity, and networkability thanworkstation computers. Given the versatility of mobile devices, it ishelpful to implement a means by which these mobile devices can interactwith servers to synchronize data and deliver email communications in thecontext of potentially intermittent, unreliable, occasionally-connected,or temporarily-unavailable networking capabilities.

As wireless networks mature and evolve, mobile devices are moving frombeing occasionally-connected to having near-constant networkconnectivity. As a function of increasing wireless network coverage andbandwidth, applications running on mobile client devices increasinglyrely upon data synchronization with back end servers such as emailservers. Current techniques for synchronizing data and email for mobiledevices often stage data to be synchronized outside of corporate andorganizational networks and firewall servers, which creates a potentialsecurity risk.

Interaction using data sets exchanged between mobile devices and centralservers often occurs in the context of exchanges of email, email events(including, but not limited to, indications that email messages havebeen read, forwarded, received, and deleted), PIM events (including, butnot limited to, reminders, meeting invitations, meeting requests, tasklists, and calendar appointments), application data, business processtasks, and information stored in databases. Mobile devices often retaina subset of some of email messages, email events, PIM events, and datafound in enterprise databases in a local data store or database forlocal access on the device while the device is not connected to awireless network. Mobile devices also retain local email archives, PIMdata stores, application data, application rendering components,application execution logic, and Input/Output (I/O) parameters needed torun applications and perform business processes. Given the resourcelimitations of mobile devices, it inefficient to store an up to datecopy of enterprise applications, PIM data stores, or databases. Asmobile devices run a variety of operating systems, software suites, andprogramming frameworks; data, application, business process, and emailsynchronization needs to be platform independent.

Some current data and communications synchronization methods aresynchronous and require that the mobile device being synchronized stayonline and connected to a network during the entire synchronizationprocess in order to provide results and acknowledgment to a server.Current ‘store and forward’ and ‘push-pull’ mobile communicationssynchronization methods are often symmetrical whereby both the mobileclient device and the email server access a copy of a database (or asubset of a database) that is staged in an intermediate, mutuallyaccessible location. Due to the fact that mobile devices are typicallyremote from the back end servers they synchronize with, synchronizationdata must often be staged on a third system that mobile devices and theback end servers can readily access. To facilitate accessibility fromroaming mobile devices, data to be synchronized is often staged outsideof an organizational or corporate firewall, thus exposing proprietaryand confidential data to security risks. In typical store and forwardsynchronization systems, data to be synchronized is sent from a ‘source’device or system to an intermediate server or node where it is storeduntil it is subsequently forwarded to the ‘target’ destination system.In these store and forward systems, the intermediate server is accessedsymmetrically by the source and destination systems. Store and forwardand push-pull data synchronization techniques also necessitate largeamounts of network traffic in order to stage data to be synchronized onan intermediate server before it is ultimately forwarded or pushed toits destination system.

Current mobile data and email synchronization techniques often result inlonger data delivery times than is desired and typically require that amobile device's General Packet Radio Service (GPRS) be on andtransmitting during the entire duration of a synchronization sessionwith a server. Most current synchronization methods require largeamounts of CPU and memory resources on mobile devices in addition torequiring that mobile devices GPRS services are running duringsynchronization, the combination of which results in rapid consumptionof mobile device battery resources.

Current email and data synchronization methods do not provide foremail-driven business process and do not enable actionable-responses onservers that complete business processes and application workflowoperations based upon operations performed on mobile devices. Whilecurrent methods may perform synchronization of data updated by anapplication, they do not include a delivery mechanism for applicationsor business process events that deliver these items to mobile devices.Although current methods include mobile services that use e-mail fornotifications and alerting, these services are limited to sending e-mailto mobile devices that request additional user input for businessprocess completion. Current systems and methods use email solely as adelivery mechanism for business-process events and lack a way for usersof mobile devices to provide actionable-responses needed in order tocomplete business processes.

Current application and PIM event synchronization methods may replicateevents by replicating the related data objects or records, butreplication often consumes more resources than re-creating events inorder to achieve synchronization. Current Event synchronizationtechniques can consume large amounts of computing resources and resultin relatively slow execution times because they synchronize Events bycomparing and reconciling changed database records associated with theEvents. PIM (i.e., calendar, task, appointment data) and emailsynchronization is normally achieved by periodically detecting changesat the record level and transferring changes from a source system to atarget system. Current methods compare one or more key fields, such asprimary or foreign keys, in database records within multiple databasesto be synchronized, which can require large amounts of computingresources and time in order to synchronize frequently-changing Events.

Accordingly, what is desired is a means of offering quicker delivery ofemail, email events, PIM events, business process events, applicationevents and application data to mobile devices that also reduces networktraffic and increases mobile device battery life. What is further isdesired are methods, systems, and computer program products forimproving synchronization of data objects such as email messages,applications, database records, and calendar entries/events betweenmobile devices and servers without staging the data objects outside ofan organization's firewall servers.

What is also desired is a means of efficiently, securely, and reliablysynchronizing email messages, applications, application events, PIMevents such as calendar entries, email events, and other data objectsbetween a plurality of mobile devices and servers without having tostage updated data on an intermediate servers. What is further desiredare methods, systems, and computer program products that synchronizedata objects and communications between mobile devices and servers in anasynchronous and symmetrical manner without requiring mobile devices tobe online during synchronization and without storing data objects to besynchronized on an intermediate server.

SUMMARY OF THE INVENTION

The invention includes methods, systems, and computer program productsfor synchronizing data objects such as email messages, applications,database records, and calendar application entries, between mobileclient devices and servers. The invention also includes methods,systems, and computer program products that allow mobilization ofbusiness processes. The methods, systems, and computer program productsoperate asynchronously, which allows them to synchronize data objectsand applications on mobile client devices that are occasionally orintermittently connected to servers they are synchronizing with. Themethods, computer program products, and systems operate symmetrically inthat either a mobile device or a back end server such as an email serveror enterprise server can initiate the synchronization of a data objectsuch as an email message, a web services request, a method call, or acalendar application appointment. The methods, systems, and computerprogram products initiate data object synchronization by invokingfunctions that reside on mobile devices and back end servers such asemail servers and enterprise servers. The data object synchronizationmethods, systems, and computer program products also serve as amechanism to deliver business-process events between mobile devices andenterprise servers. The methods, systems, and computer program productsprovide actionable-responses from mobile devices to enterprise serversin order to facilitate completion of business processes.

In accordance with an embodiment of the invention, the methodsynchronizes updated, inserted, and deleted data objects such as emailmessages and calendar entries between a mobile device and an emailserver by invoking a sequence of functions that route the data andresult from a mobile device to an email server via a synchronizationserver. Similarly, the method also synchronizes new, updated, anddeleted data objects between an email server and a mobile device byinvoking the sequence of functions in reverse in order to route the dataobjects and results from a mobile device to an email server via asynchronization server.

The method further delivers data and code necessary to create and runapplications dynamically on mobile devices. The method deliversapplications to mobile devices, wherein the applications includerendering components, execution logic or executable code, andInput/Output (I/O) parameters. In an embodiment, the method deliversapplications from enterprise servers to mobile client devices and‘synchronizes’ applications by sending application data back to theenterprise servers after the applications are executed on mobileclients. In another embodiment, the method synchronizes applications byre-running an application on an enterprise server using input and outputcaptured on mobile devices where the applications were previously run.The method includes back-end integration whereby applications arecreated dynamically via a toolkit that ties enterprise applications tostandard interfaces. The method delivers applications as a businessprocess of enterprise applications. In an embodiment, web services anddata objects such as business process ‘widgets’ are delivered to anenterprise server in a form that executes on the server after deliveryfrom a mobile device with the I/O parameters that were used and capturedon the mobile device.

The invention also includes a computer program product comprising acomputer usable medium having computer program logic recorded thereonfor enabling a processor to synchronize new, updated, and deleted dataobjects between a mobile device and a server. The computer program logicoperates asynchronously and symmetrically to synchronize data objectssuch as email messages, PIM events such as calendar entries, and emailevents between a mobile device running a client sync agent and an emailserver running a server sync agent.

The invention additionally includes a system capable of synchronizingdata objects such as email messages, PIM events, email events,applications, and calendar entries between a plurality of mobile devicesand a plurality of servers. The system includes a listening moduleconfigured to determine whether there is a data object to synchronizefrom a source mobile device to a destination server, an event deductionmodule a flagging module configured to notify the destination serverthat there is a data object to be synchronized, a caching moduleconfigured to cache the data object to be synchronized on thedestination server, a determining module configured to determine whetherthe source mobile device is online, a queuing module configured to queuedata synchronization until the mobile device is online, and asynchronization module configured to synchronize the data object on thedestination server and to return results to the source mobile device. Inaccordance with an embodiment, the system also synchronizes data objectsfrom a source server such as an email or enterprise server to adestination mobile device through use of a listening module on theserver configured to determine whether there is a data object tosynchronize from the server to a destination mobile device, a flaggingmodule configured to notify the destination mobile device that there isa data object to be synchronized, a caching module configured to cachethe data object to be synchronized on the mobile device, a determiningmodule configured to determine whether the source mobile device isonline, a queuing module configured to queue data synchronization untilthe mobile device is online, and a synchronization module configured tosynchronize the data object on the destination mobile device and toreturn results to the source server.

The invention also includes systems, methods, and computer programproducts for event-based synchronization of two or more data sources byre-creating events, including, but not limited to PIM and email events.In an embodiment, instead of comparing actual database records orfields, the method detects and track events that occur on one or moredata source sites, such as a mobile device and an email server, andrecreates those events on the target system, thus keeping eventssynchronized. In an embodiment, the method tracks events as they occuron a mobile device and an email server. The method queues recordscorresponding to events for the target system, wherein the target systemmay be a PIM server, an enterprise server, an email server, or a mobiledevice. Once received on the target system, the queued events are‘replayed’ on the target using a similar sequence of operations thatwere detected on the source system. Once the events are replayed on thetarget system, data objects such as documents, database records, files,and data fields corresponding to the events are replicated between thesource and target systems and the respective data sources aresynchronized. The method detects and tracks user events on target andsource systems. These detected events are then sent across throughmessage queues on the respective systems. When these queued actions areplayed back on the target system, the respective data stores on thesource and the target systems are synchronized. The method tracks anddetects events including, but not limited, receipt of an email message,reading of an email message (i.e., when an email message is flagged ormarked as read), forwarding an email message, creation of a meetingrequest, acceptance of a meeting request, creation of a task, receipt ofa task reminder, movement of an email message or item to a subfolder,deletion of one or more email messages, creation of an email subfolder,and deletion of an email subfolder.

Further features and advantages of the invention, as well as thestructure and operation of various embodiments of the invention, aredescribed in detail below with reference to the accompanying drawings.It is noted that the invention is not limited to the specificembodiments described herein. Such embodiments are presented herein forillustrative purposes only. Additional embodiments will be apparent topersons skilled in the relevant art(s) based on the teachings containedherein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the relevant art to make anduse the invention.

FIG. 1 depicts a mobile data environment, in accordance with anembodiment of the present invention.

FIG. 2 illustrates a modular view of a synchronization system, inaccordance with an embodiment of the present invention.

FIG. 3 illustrates synchronization engines, synchronization agents,listeners, and data stores, in accordance with an embodiment of thepresent invention.

FIG. 4 illustrates a modular view of a business process mobilization andapplication workflow system, in accordance with an embodiment of thepresent invention.

FIG. 5 depicts a business process mobilization and application workflowarchitecture, in accordance with an embodiment of the present invention.

FIG. 6 provides a legend for function calls depicted in the messagesequence charts of FIGS. 7 and 8.

FIG. 7 provides a Message Sequence Chart (MSC) of synchronizing anewly-composed email between a mobile device and an email server, inaccordance with an embodiment of the present invention.

FIG. 8 provides an MSC of synchronizing data objects between mobiledevices and servers, in accordance with an embodiment of the presentinvention.

FIG. 9 illustrates an event-based synchronization system architectureand method, in accordance with an embodiment of the present invention.

FIG. 10 is a flowchart illustrating steps by which data objects areasynchronously synchronized between mobile devices and servers, inaccordance with an embodiment of the present invention.

FIG. 11 is a flowchart illustrating steps by which data objects aresymmetrically synchronized between mobile devices and servers, inaccordance with an embodiment of the present invention.

FIG. 12 depicts an example computer system in which the presentinvention may be implemented.

The present invention will now be described with reference to theaccompanying drawings. In the drawings, generally, like referencenumbers indicate identical or functionally similar elements.Additionally, generally, the left-most digit(s) of a reference numberidentifies the drawing in which the reference number first appears.

DETAILED DESCRIPTION I. Introduction

The present invention relates to systems, methods, and computer programproducts for synchronizing data objects, applications, and businessprocesses, between mobile client devices and back end servers such asemail servers, application servers, and database servers.

A data object is any textual, audio, graphical, video, or written workencoded in digital form and encapsulated in a computer readablestructure, such as a file, message, computer readable medium, or sharedmemory object; that a software application program can access andmanipulate. Unless specifically stated differently, a data object isinterchangeably used herein to identify an email message, applicationdata, a calendar entry (such as an appointment in a calendarapplication), a web services request, a method call, a database record,a data store record, and/or communications data. A method call is aninvocation of a subroutine or Java applet. A method such as a subroutineor applet can consist of a sequence of statements that perform anaction, a set of input parameters used to tailor or customize theactions, and a return or output value. Methods provide a mechanism foraccessing data by reading from and writing to the data. A method callmay be modeled in terms of passing a message or request to an object.Instead of directly performing an operation on an object, a method callwith corresponding input/output (I/O) parameters is sent to the objectto instruct the object what operation it should perform. At this point,the object either performs the operation, or if the requested operationcannot be performed, the object raises an exception describing why theoperation cannot be carried out. A web service is a software systemdesigned to support interoperable interaction between servers andcomputers (including mobile devices) over a network. A web service maybe a web application programming interface (API) that can be accessedover a network, such as a wireless network or the Internet, and executedon an enterprise server such as an application server or email serverthat hosts the requested web service(s).

An application is any software program or web service that can beexecuted or run on a server, computer, or mobile client device. Anapplication includes at least a rendering component, execution logic,and Input/Output (I/O) parameters. An application's execution logic maybe in the form of binary executable code or scripting programming/markuplanguages such as HyperText Markup Language (HTML), Extensible HTML(XHTML), Java, JavaScript, or AJAX (Asynchronous JavaScript and XML).One of skill in the relevant arts will appreciate that other programminglanguages and technologies can be used for an application's executionlogic.

In accordance with an embodiment of the present invention, the dataobject synchronization methods and systems described herein serve asdelivery mechanisms for applications and the workflow operationsassociated with the applications (i.e., application workflow events).Application workflows are comprised of related application operations.Application operations may be distributed amongst a plurality of serversand mobile devices, and therefore may not be performed sequentially.Application operations may include one or more of data entry, datadeletion, data update, approval of requests, receipt confirmations,acknowledgment of alerts, and other events. An application workflow istypically composed of multiple related operations. These applicationoperations may be encapsulated as ‘application events.’ Applicationevents occur when application operations are completed or performed. Inan embodiment, application workflows are mobilized and distributedbetween servers and mobile devices by synchronizing application events.For example, application event synchronization may be performed throughemail and data synchronization.

PIM and email events are any actions performed on PIM items or emailmessages. PIM and email events include, but are not limited to, deliveryof a new email message, forwarding an email message, deletion of anemail message, movement of an email message or item to a subfolder,deletion of one or more email messages, creating of an email subfolder,deleting of an email subfolder, receiving an email message, placing anemail message in a folder, marking an email message as unread, readingan email message, receiving a meeting request, accepting meetingrequest, forwarding a meeting request, declining a meeting request,rescheduling an appointment or meeting, creation of a task, receiving atask reminder, forwarding a task reminder, delegating a task, andrescheduling a task. Email events may be indicated as flags associatedwith email messages, such as flags indicating an email has been read,forwarded, delivered, and marked for deletion.

A business process is any collection of interrelated tasks which solve aparticular problem or issue for an organization or enterprise. Abusiness process may be a series of steps designed to produce a result.Business processes may result in an outputs or services that arereceived by users outside the organization. Other processes produceoutputs that are not visible outside of the organization. Businessprocesses can govern the operation of a system such as operationalbusiness processes that perform purchasing, manufacturing, marketing,and sales tasks in an organization. Supporting business processes suchas accounting, benefits, information technology (IT), and humanresources/recruiting, support an organization's core processes. Abusiness process can be decomposed into several sub-processes, whereinthe respective sub-processes have their own attributes, and wherein thesub-processes contribute to performing the overall task of the businessprocess. Complex business processes link multiple organizations orenterprises through business process management and activity monitoringtools.

In accordance with an embodiment of the present invention, businessprocesses are mobilized using the data object synchronization approachdisclosed herein to enable business and application workflow events tobe ‘synchronized’ between enterprise servers and mobile devices. Forexample users of mobile devices can perform actions to complete businessprocesses, such as approval of expense reports, human resourcerequisitions and purchase orders, or notifications from Customerrelationship management (CRM) activities.

According to an embodiment, a web services interface provides seamlessserver integration with mobile devices via use of business processwidgets. Widgets are objects or applets on a computer display that auser interacts with. Business process widgets contain information aboutbusiness process events as well as information that describes a userinterface (UI) layout. Business process widgets may include ExtensibleMarkup Language (XML) script or binary data that describes a businessprocess event and a UI layout. For example, business process widgets mayinclude Extensible Application Markup Language (XAML) script or code.Business process widgets can be self contained or can interact withnative applications resident on a mobile device or server and can invokenative applications. For example, a business process widget may includea Uniform Resource Locator (URL) link that launches a web browser on amobile device such as Internet Explorer Mobile. For example, a widgetmay be a data object on a mobile device display screen that users of themobile device interact with. Widget applets provide access to data andapplications such as calendar applications. A widget may be astand-alone, task-oriented application which can be composed of severalrelated interactions or processes. A software system, such as a webbrowser, can run or execute widgets.

Business process widgets are abstractions of simple business processesor sub-processes. In an embodiment, business process widgets arecustomized to suit typical applications that can be deployed to mobiledevices. Examples of business process and application widgets includepurchase order approval, human resources approval processes, expensereport approval process, sales and marketing processes, CRM activitiesnotification, and Really Simple Syndication (RSS) format Internet feednotifications.

According to embodiments of the invention, data objects, applications,and business process widgets on mobile client devices are synchronizedby calling or invoking symmetrical functions residing on servers andmobile devices. While the present invention is described herein withreference to illustrative embodiments for particular applications, itshould be understood that the invention is not limited thereto. Thoseskilled in the art with access to the teachings provided herein willrecognize additional modifications, applications, and embodiments withinthe scope thereof and additional fields in which the invention would beof significant utility.

The detailed description of embodiments of the present invention isdivided into several sections. The first section describes a system forsynchronizing data objects such as email messages, calendar updates,application data, and database records between mobile client devices andservers such as email servers and back end database servers. Subsequentsections describe systems and methods for mobilizing business processesand synchronizing application workflow and PIM events between enterpriseapplication servers and mobile devices.

FIG. 1 depicts a mobile environment 100 that allows mobile devices 160a-c to synchronize email with email server 126 over the Internet 102, inaccordance with an embodiment of the present invention. While thisembodiment is described in terms of email, it is applicable to otherdata objects. One skilled in the relevant arts will appreciate that anynetwork, such as a corporate intranet, may be used instead of theInternet 102. Server sync agent 128 on email server 126 synchronizesemail delivery between mobile devices 160 a-c and email server 126 vianetwork 172. Mobile device 160 a accesses network 172 via network accessserver 112 a in order to send and receive email to and from email server126. Mobile devices 160 b and 160 c access network 172 via networkaccess server 112 b in order to synchronize email with email server 126.

Mobile devices 160 a-c may be one of many devices commonly designated asmobile clients, such as, but not limited to, personal digital assistants(“PDAs”), devices operating according to the Microsoft Pocket PCspecification with the Microsoft Windows® CE operating system (OS),devices running the Microsoft Windows® Mobile Standard OS, devicesrunning the Microsoft Windows® Mobile Professional OS, devices runningthe Symbian OS, devices running the Palm OS®, mobile phones, BlackBerry®devices, smart phones, hand held computers, palmtop computers, laptopcomputers, ultra-mobile PCs, and other wireless mobile devices capableof running mobile applications.

Sync engine object 124 also allows mobile devices 160 a-c to receive themost current data available on synchronization server 122. Client syncagents 164 a-c running on mobile devices 160 a-c enable mobile devices160 a-c to upload their most current data to database 114 onsynchronization server 122 for any given application or set ofapplications. For example, a calendar application might allow otherusers to add or make changes to appointments which are then stored onsynchronization server 122. A user of mobile device 160 a may also haveadded, deleted, or made changes to appointments within mobile device 160a itself.

Unless specifically stated differently, a user is interchangeably usedherein to identify a human user, a software agent, or a group of usersand/or software agents. Besides a human user who needs to synchronizeemail, data, and calendar entries, a software application or agentsometimes needs to synchronize these items. Accordingly, unlessspecifically stated, the term “user” as used herein does not necessarilypertain to a human being.

Upon synchronization, synchronization server 122 learns of theappointments made, changed, or deleted on mobile device 160 a, andmobile device 160 a learns of appointments made, changed, or deleted onsynchronization server 122. In accordance with an additional embodimentof the present invention, a partial synchronization is possible, wherebysome subset of appointments may be exchanged. According to anembodiment, the subset of appointments are determined based uponcriteria including, but not limited to, available memory on a mobiledevice, user permissions or roles on a mobile device, available networkbandwidth between email server 126 and a mobile device, centralprocessing unit (CPU) speed on a mobile device, available storage spaceon a mobile device, and other factors. In an embodiment, the criteria orrules for determining which subset of appointments will be synchronizedis stored in a data store or database accessible by synchronizationserver 122.

In accordance with an embodiment, data stored in database 114 hosted bysynchronization server 122 may also be synchronized with local datastores or databases residing on client devices 160 a-c. “Data” as usedherein may be any object, including, but not limited to, information inany form (text, video, audio, etc.) and applications.

In another embodiment, applications can be synchronized betweenEnterprise Servers and mobile devices. Application synchronization isachieved via methods and systems similar to those described herein tosynchronize data objects. The methods and systems that deliverapplications from enterprise servers to mobile devices deliverapplication executables along with input/output parameters to the mobiledevices. For example, data and/or code necessary to create and run anapplication is dynamically delivered to mobile devices. For example, forsome applications, only the data needed to run the applications isdelivered to a mobile device. For other applications, application codeand associated data needed to run the applications is delivered to amobile device. An Application includes at least a rendering component,execution logic, and Input/Output (I/O) parameters. According to anembodiment of the present invention, applications are delivered fromenterprise servers to mobile devices and after these applications areexecuted on mobile clients, the application is synchronized onenterprise servers by re-running or executing the application onenterprise servers with the I/O captured from mobile devices.

According to an embodiment of the present invention, applicationcompletion processes are delivered to mobile devices in a concise andcapsular manner by encapsulating processes and workflow that needs to beexecuted by applications running on back end or enterprise server. Forexample, there is back-end integration whereby applications are createddynamically via a toolkit that ties enterprise applications to standardinterfaces. Applications are delivered as a business process of theenterprise applications. Web services, widgets, and data objects aredelivered in a form that runs on a server after delivery from mobiledevices with the I/O parameters that were used on the mobile devices.

Mobile environment 100 is commonly a persistent network connection overa cellular provider network, and communications travel over the Internet102. However, mobile environment 100 may be any communication means bywhich synchronization server 122, email server 126, and mobile devices160 a-c may interact, such as a docking cradle, Wide Area Network (WAN),Local Area Network (LAN), Wireless Local Area Network (WLAN), infrared,or Bluetooth. The degree of availability of access to the communicationmeans employed may vary greatly, and users of mobile devices 160 a-c maygo for days without synchronizing with synchronization server 122 oremail server 126, or may be able to synchronize constantly whenconnected to a WAN.

In a typical mobile environment such as mobile environment 100, multiplemobile devices 160 a-c synchronize with email server 126 viasynchronization server 122. Synchronization server 122 and email server126 need not be a single physical computer, and may in fact compriseseveral computers distributed over a number of physical and networklocations. For the purposes of illustration, synchronization server 122and email server 126 are depicted as single points of access in mobileenvironment 100. Synchronization server 122 and email server 126 neednot be separate physical computers either, and may in fact comprise asingle computer as the functionality of synchronization server 122 maybe performed by a virtual machine running on email server 126.Conversely, the functionality of email server 126 may be performed by avirtual machine executing on synchronization server 122.

II. Synchronization Systems

FIG. 2 depicts synchronization system 200 in which mobile device 160 iscapable of synchronizing with synchronization server 122 via interface230. In accordance with an embodiment of the present invention,interface 230 facilitates calls between sync engine object 124 runningon synchronization server 122 and client sync agent 164 running onmobile device 160. In an embodiment, interface 230 is comprised offunctions that are called to pass data and variables between mobiledevice 160 and synchronization server 122. In an embodiment,synchronization system 200 is operable to synchronize a database 114located at synchronization server 122 with a local data store ordatabase located at mobile device 160. In another embodiment, database114 is remote to synchronization server 122.

Synchronization system 200 is also operable to synchronize email betweenemail server 126 and synchronization server 122 via interface 232.According to an embodiment of the invention, interface 232 facilitatesfunction calls between sync engine object 124 hosted on synchronizationserver 122 and server sync agent 128 running on email server 126. In anembodiment, interface 232 is comprised of functions that are called topass email messages and associated data between email server 126 andsynchronization server 122. Email is then synchronized on mobile device160 by passing email messages and data from synchronization server 122via interface 230.

When a user composes a new email message on mobile device 160, clientsync agent 164 running on mobile device 160 is operable to deliver thenew email message and associated data to sync engine object 124 onsynchronization server 122 via interface 230. After the new emailmessage is received at synchronization server 122, it is delivered toserver sync agent 128 on email server 126 via interface 232.

FIG. 3 depicts the components of synchronization system 300, accordingto an embodiment. Synchronization system 300 includes sync engine object124, the sync agents, the data stores, and listeners used to synchronizeemail between mobile device 160, synchronization server 122, and emailserver 126, in accordance with an embodiment of the present invention.In the synchronization process performed by synchronization system 300,three mobile ‘objects’ handle the synchronization of email and databetween mobile client 160, synchronization sever 122, and email server126. The main server side object is sync engine object 124. Sync engineobject 124 works in coordination with client sync agent 164, which is anobject running on mobile device 160. Client sync agent proxies 366represent the proxy objects used to reach client sync agent 164 onmobile device 160 and server sync agent 128 on email server 126.Asynchronous function calls between the sync engine object 124, clientsync agent 164, and server sync agent 128 are handled by the respectiveclient sync agent proxies 366 on mobile device 160 and email server 126.

Sync engine object 124 calls server sync agent 128, which handles theactual back-end server-side personal information manager (PIM) provider.In accordance with an embodiment of the invention, the PIM provider maybe one of many applications commonly designated enterprise emailapplications, such as, but not limited to, Microsoft Exchange, LotusDomino, and Novell GroupWise.

According to an embodiment, synchronization system 300 is operable tosynchronize portions of database 114 located on synchronization server122 with a local data store or database located at mobile device 160. Inanother embodiment, database 114 is remote to synchronization server122.

In an embodiment, the data store on mobile device 160 is native PIM datastore 316. For example, native PIM data store 316 may be a PocketOutlook Object Model (POOM) data store, a Messaging ApplicationProgramming Interface (MAPI) data store, or another data store native toa specific application running on mobile device 160. Mobile PIM datastore 318 is used to store results of local operations on mobile device160. Mobile listener object 320 detects data changes (including, but notlimited to data updates, deletes, and insertions) on mobile device 160.

In an embodiment, server sync agent 128 is a local object resident onemail server 126 that uses a local PIM data store 342 to read and writedata to native databases such as local email database 340, and serversync agent 128 is notified of changes by a local email listener 344resident on email server 126. In another embodiment, components such asone or more of server sync agent 128, email database 340, PIM data store342, and email listener 344 are remote to email server 126. When emailserver 126 is notified of a change in local email database 340, it usesPIM data store 342 to read the actual data object change, and then emaillistener 344 notifies server sync agent 128 of the change. From there,server sync agent 128 relays the change to client sync agent 164 that isparticipating in the synchronization via sync engine object 124 onsynchronization server 122.

Server sync agent 128 and client sync agent 164 work in conjunction witheach other to implement interface 232 that sync engine object 124, canuse to insert, update, and/or delete email, data, and calendar records.In accordance with an embodiment of the invention, data is passed alonginterface 232 by function calls between a local interface in sync engineobject 124 on synchronization server 122 and client interface 348 onemail server 126. In an embodiment, the functional components ofinterface 232 are depicted as pseudo-code below:

 // Updates the given data object in the given data store  virtual voidUpdateRecord(   int iDeviceId, // (in) the device ID for the update(needed on server agents, but not necessary for clients)   eSyncDatastoreType DsType, // (in) the data store to update   CmoBinary& Id, //(in/out) the record ID to update   CmoBinary& // (in) the wbxmlrepresentation of the   RecordData, // XMLRecord   tSyncRecordVer& //(in/out) The previous Version of   Version, // the data object. If thecurrent value does // not match the given value, then the Update // callmust return a SYNC_ERR_CONFLICT // exception. On successful update, the// new Version value should be returned.  ) = 0;  // Adds a new dataobject to a data store  virtual void NewRecord( TempId,  ///(in) Atemporary record ID assigned by the caller to identify the data object    LastMod, ///(in/out) A unique value that identifies the /// current‘revision’ of the data object /// Could be a lastMod date/time, changecounter, /// or checksum. Needs to be /// a value that is modified everytime the /// data object is modified.    RecordId /// (out) The actualrecord ID used for /// the data object after the data object has beeninserted.  );  // Deletes a data object from a data store  virtual voidDeleteRecord(   int iDeviceId, // (in) the device ID for the update(needed on server agents, but not necessary for clients)   eSyncDatastoreType DsType, // (in) the data store to delete from   CmoBinary& Id,// (in) the record ID to delete   tSyncRecordVer& // (in) The previousVersion of   Version, // the data object. If the current value does //not match the given value, then the DeleteRecord // call must return aSYNC_ERR_CONFLICT // exception.  ) = 0;

Sync engine object 124 implements another interface 230 that server syncagent 128 and client sync agent 164 can call when they detect localchanges that need to be synchronized to each other via synchronizationserver 122. Server sync agent 128 and client sync agent 164 work inconjunction with each other to implement interface 232 that sync engineobject 124, can use to insert, update, and/or delete email, data, andcalendar records. In accordance with an embodiment of the invention,data is passed along interface 230 by function calls between a localinterface in sync engine object 124 on synchronization server 122 andclient interface 346 on mobile device 160. In an embodiment, thefunctional components of interface 230 are depicted as pseudo-codebelow:

 // Called by a device when a new or modified data object has been detected virtual void ClientRecordChanged(   char* DevId, // (in) thefull device ID with the modified/new data object   eSyncData storeTypeDsType, // (in) the data store with the modified/new data object  CmoBinary& Id, // (in) the data object ID   CmoBinary& RecordData, //(in) the data object contents   tSyncRecordVer Version // (in) thecurrent version of the data object   ) = 0;  // called by a device whena data object has been deleted  virtual void ClientRecordDeleted(  char* DevId, // (in) the full device ID with the modified/new dataobject   eSyncData storeType DsType, // (in) the data store with themodified/ new data object   CmoBinary& Id // (in) the data object ID   )= 0;  // Called by a server listener when a new or modified data objecthas been detected  virtual void ServerRecordChanged(   UI32 DevId, //(in) the device ID with the modified/ new data object (unique int deviceID as stored in database)   eSyncData storeType DsType, // (in) the datastore with the modified/ new data object   CmoBinary& Id, // (in) thedata object ID   CmoBinary& RecordData, // (in) the data object contents  tSyncRecordVer Version // (in) the current version of the data object  ) = 0;  // called by a server listener when a data object has beendeleted  virtual void ServerRecordDeleted(   UI32 DevId, // (in) thedevice ID with the modified/ new data object (unique int device ID asstored in database)   eSyncData storeType DsType, // (in) the data storewith the modified/ new data object   CmoBinary& Id // (in) the dataobject ID   ) = 0;

FIG. 4 depicts business process mobilization and application workflowsystem 400 that facilitates application workflow and applicationsynchronization between mobile device 160 and enterprise applicationserver 427. FIG. 4 is described with continued reference to theembodiments illustrated in FIGS. 1-3. However, FIG. 4 is not limited tothose embodiments. In accordance with an embodiment of the presentinvention, mobile office server 437 resident on synchronization server122 facilitates calls between email/back end server 126, enterpriseapplication server 427, and mobile device 160.

According to an embodiment of the present invention, business processwidgets are deployed to mobile device 160 and stored in a client-sideenterprise mobility framework container resident on mobile device 160.For example, an enterprise mobility framework container is local tomobile device 160 and may be integrated with an email or messaging inboxon mobile device 160. In another embodiment, the enterprise mobilityframework container is local to mobile device 160 and is a standaloneapplication on mobile device 160. Business process widgets are deployedfrom administration console 439. Administration console 439 may be aseparate computer or server accessible by administrators responsible fordeploying business process widgets. Alternatively, administrationconsole 439 may be a user interface accessible by adminstratorsresponsible for deploying business process widgets. According to anembodiment, business process widgets deployed by administration console439 provide native customization through extensions registers. Mobileoffice server 437 stores business process widgets and delivers them tomobile device 160.

The Enterprise mobile framework container on mobile device 160interprets the content and data flow of business widgets delivered frommobile office server 437 via interface 230. Mobile office server 437also provides rendering information to mobile device 160. In anembodiment, the rendering information is provided through XML documents.Business process widgets also contain flow-control information andaction description properties.

Synchronization of data objects, business processes, applications, andapplication data between email server 126 and mobile device 160 isperformed as described above with respect to FIGS. 2 and 3. Data objectsto be synchronized, such as email messages and calendar entries, aresent via interface 232 between email server 126 and synchronizationserver 122. Similarly, data objects to be synchronized are sent betweenmobile device 160 and synchronization server 122 via interface 230. Inembodiments of the present invention, data object synchronizationsystems 200 and 300 depicted in FIGS. 2 and 3 are used to deliverapplications from enterprise application server 427 to mobile device160, wherein the applications include rendering components, executionlogic, application data, and Input/Output (I/O) parameters. For example,synchronization systems 200 and 300 deliver applications and applicationdata from enterprise application server 427 to mobile device 160 viasynchronization server 122. Similarly, synchronization systems 200 and300 deliver application workflow events (business process events) frommobile device 160 to enterprise application server 427 viasynchronization server 122. In an embodiment, synchronization server 122contains a mobile office server 437 that coordinates delivery ofapplications and application data between mobile device 160 andenterprise application server 427. Mobile office server 437 may besoftware resident on synchronization server 122. In an embodiment notdepicted in FIG. 4, mobile office server may be a distinct, separateserver and not resident on synchronization server 122.

When an application is executed on mobile device 160, the correspondingapplication workflow event is executed again on enterprise applicationserver 427 by sending application data and I/O parameters from mobiledevice 160 to enterprise application server 427 via synchronizationserver 122. In an embodiment, I/O parameters such as data entry andresults for an application executed on mobile device 160 are capturedand sent to enterprise application server 427 via synchronization server122. The captured I/O parameters are used on enterprise applicationserver 427 to execute the corresponding enterprise edition or version ofthe application that was executed on mobile device 160. In this way, theapplication is ‘synchronized’ between mobile device 160 and enterpriseapplication server 427 by effectively re-running the application usingthe same data input by a user of mobile device 160 and with the sameresult/output parameters captured on mobile device 160. According to anembodiment, data object synchronization systems 200 and 300 synchronizeapplications by re-running applications on enterprise application server427 using input and output captured on mobile device 160 where theapplications were previously run.

According to embodiments of the present invention, data objectsynchronization systems 200 and 300 are used to deliver business processwidgets between mobile office server 437 and mobile device 160.

FIG. 5 depicts the components business process widget and applicationworkflow system 500. Business process mobilization and applicationworkflow system 500 mobilizes business processes and facilitatessynchronization of application workflow events between mobile device 160and enterprise application server 427. FIG. 5 is described withcontinued reference to the embodiments illustrated in FIGS. 1-4.However, FIG. 5 is not limited to those embodiments. According to anembodiment, mobile office server 437 on synchronization server 122facilitates calls between email/enterprise server 126, enterpriseapplication server 427, and mobile device 160.

Components on synchronization server 122 enable application workflowevents and business process widgets to be synchronized between mobiledevice 160 and enterprise application server 427.

Mobile office server 437 includes server-side widget repository 533 tostore business process widgets deployed by administration console 439.Repository 533 includes information to correlate individual businessprocess widgets to known mobile office users. Repository 533 alsocontains widget version information to enable versioning of businessprocess widgets. Repository 533 is available to users and processes viasingle sign-on (SSO) interfaces.

Mobile office server 437 also includes application message processengine 535 that facilitates application workflow event synchronizationvia email messages. Application message process engine 535 presentsemail messages with a custom view based on the application workflowevent being synchronized. Application message process engine 535 alsoprovides actionable-responses from mobile device 160 in order tocomplete business processes. In an embodiment, application messageprocess engine 535 accomplishes this application workflow eventsynchronization through mobile web services. Application message processengine 535 consolidates the application workflow event synchronizationbetween mobile device 160 and enterprise application server 427 in amobile device email inbox 545. Mobile device email inbox 545 is a singleinbox on mobile device 160 used to receive email messages, applications,and business widgets from mobile office server 437.

Enterprise mobile framework container 543 is a client-side datacontainer resident on mobile device 160. According to one embodiment ofthe present invention, enterprise mobile framework container 543 may beintegrated with mobile device email or messaging inbox 545. In anotherembodiment, enterprise mobile framework container 543 is an independentapplication not integrated with email or messaging inbox 545. Enterprisemobile framework container 543 also provides native customization forapplications on mobile device 160 through extensions. Enterprise mobileframework container 543 registers and interprets business widget contentand flow received from mobile office server 437.

In an embodiment, there are server components on enterprise applicationserver 427 to integrate applications executed on mobile device 160 withback-end applications and web application that combine data from morethan one source into a single integrated tool, such as a Mash-uptechnologies. This back-end integration is configured by businessprocess toolkit 529 that allows administrators to dynamically createapplications. Business process toolkit 529 ties enterprise applicationsresident on enterprise application server 427 to standard interfaces. Inan embodiment, web services and data objects such as business process‘widgets’ are delivered to enterprise application server 427 in a formthat executes on enterprise application server 427 after delivery frommobile device 160 with the I/O parameters that were used and captured onmobile device 160.

In an embodiment, business widget and application workflow eventsynchronization leverages data object synchronization system 300 byusing e-mail for notifications and alerting regarding applicationexecution.

III. Function Calling Sequences

FIG. 6 contains a key 600 illustrating four different items used todepict function calls and invocations in the message sequence charts ofFIGS. 7 and 8. Key 600 includes a function call where a result or anacknowledgement is expected in return, a function call returning aresult or acknowledgment, an asynchronous function call, and anasynchronous function call returning results.

FIG. 7 is a message sequence chart (MSC) 700 depicting the initialcalling sequence that occurs when a new email arrives on an email serverand is synchronized to a mobile device, in accordance with an embodimentof the invention. FIG. 7 is described with continued reference to theembodiments illustrated in FIGS. 1-3. However, FIG. 7 is not limited tothose embodiments. FIG. 7 illustrates the calling sequence for ascenario where a user of mobile device 160 receives a new email on emailserver 126 and then mobile device 160 connects at a subsequent time andgets the email.

In step 750, when server email listener 344 detects a new email, itreports the new email to sync engine object 124 by calling the NewRecordfunction. Next, sync engine object 124 will create an instance of theclient sync agent object for the appropriate device and call theInsertRecord function.

In accordance with an embodiment, this InsertRecord call is made as anasynchronous guaranteed delivery function call. For now, email listener344 on email server 126 is finished.

Client sync agent proxy 366 represents the proxy object used to reachthe client sync agent 164 that is running on a mobile device such asmobile device 160. At this point, client sync agent proxy 366 initiatesAsyncMethodInvocation call to client interface for server 348. Thisfunction call is asynchronous and guaranteed to succeed, so at thispoint client sync agent proxy 366 returns results from the InsertRecordfunction call.

In accordance with an embodiment of the present invention, informationfor the AsyncMethodInvocation method call is saved in the Request Cache,and when the mobile device hosting the client interface for mobiledevice 246 is offline, the request in AsyncMethodInvocation will bedelivered and executed by client sync agent 164 at a later time.

Once the client-side InsertRecord call has been executed by client syncagent 164, client sync agent 164 will run a callback on sync engineobject 124 to inform it that the InsertRecord call has been completed.

When a new email is composed on mobile device 160, the function sequencedescribed above runs in reverse. In this way, email synchronizationbetween mobile devices and email servers is handled in a symmetricalmanner. In an embodiment, the function invocations depicted in FIGS. 7and 8 may be web service requests from synchronization server 122 oremail server 126 that occur once mobile device 160 connects to a networksuch as network 172 depicted in FIG. 1. Similarly, the function calls inFIGS. 7 and 8 may be web service requests from a mobile device 160 to anemail server 126 occurring when mobile device 160 connects to network172. According to an embodiment, these symmetrical web requests occurwhen new emails either arrive at email server 126 or are composed onmobile device 160. This symmetrical calling sequence is described ingreater detail with reference to FIG. 7 below.

FIG. 8 is a message sequence chart (MSC) 800 depicting the functioncalling sequence that occurs when new emails and data objects arrive ona server and are synchronized to a mobile device, in accordance with anembodiment of the invention. FIG. 8 is described with continuedreference to the embodiments illustrated in FIGS. 1-3. However, FIG. 8is not limited to those embodiments.

As depicted in FIG. 8, a server such as email server 126 makes a requestto a client such as mobile device 160 via sync engine object 124. Thefunction calling sequence begins when the server side listener detects anew or updated data object. Upon detection 850 of a new or updated dataobject, the server side listener reports the new or updated data objectto local server sync agent 128. Next, server sync agent 128 calls theServerRecordChanged function in order to pass the new or updated dataobject to sync engine object 124.

According to an embodiment, sync engine object 124 will then look intoits local ID map (described below in section IV.) to determine if thedata object has already synchronized this particular data object to themobile device. Sync engine object 124 will then use a call to invoke theUpdateRecord method on client sync agent 164. When the sync engineobject 124 determines that there is no existing record ID mapping in itsID map, it will use an empty RecordId in the call to UpdateRecord.

Client sync agent proxy 366 is the proxy object that is used to reachthe client sync agent 164 running on mobile device 160. According to theembodiment depicted in FIG. 8, client sync agent proxy 366 initiates anAsyncMethodInvocation call to the client interface for server 348. Thisfunction call is asynchronous and guaranteed to succeed, so at thispoint sync engine object 124 returns from the ServerRecordChangedfunction call.

In step 852, information for the AsyncMethodInvocation method call issaved in the Request Cache, and if the mobile device hosting the clientinterface for mobile device 246 is offline, the request inAsyncMethodInvocation will be delivered and executed by client syncagent 164 later.

When client sync agent 164 receives the call to UpdateRecord, it may usethe PIM data store objects to insert the data object into its mobile PIMdata store, such as mobile PIM data store 318 depicted in FIG. 3. Instep 854, when the mobile device connects to the server running serversync agent 128, the outstanding AsyncMethodInvocation call toInsertRecord is run to insert the new data object on the mobile device.

After the data object is inserted, client sync agent 164 knows the realRecordID that was used for the new object so that client sync agent 164can return the new RecordId for the output ID argument in theUpdateRecord results.

In step 856, results are stored in the Results Cache on the mobiledevice running client sync agent 164 until they are successfullydelivered to the server in case the connection to the server is lost.

At this point, if the client is connected to the server, UpdateRecordresults are passed from client sync agent 164 back to sync engine object124 via an UpdateRecord call. Once synchronization server 122 has theresults from this UpdateRecord call, it will run a callback on syncengine object 124 to indicate that an outstanding call has completed.Then, sync engine object 124 can retrieve the results from anUpdateRecord(GetResults) call.

Once sync engine object 124 has the results and the new RecordID thatmobile device 160 actually used, it can update the mapping in its localID map so that mobile device 160 knows the device local uniqueidentifier (LUID) in case the data object later needs to be updated ordeleted. Once sync engine object 124 has processed the results of thisUpdateRecord call, it informs client sync agent 164 that it has finishedprocessing the Asynchronous results from the previous UpdateRecord callvia an UpdateRecord(finished) call so that synchronization server 122can clean up by removing the data from the Results Cache.

The function call sequence described above runs in reverse when a usercomposes a new email, creates a new data object, or updates a dataobject on mobile device 160. This calling sequence is described in thefollowing paragraphs, but is not depicted in FIG. 8.

When a user composes a new email on mobile device, such as mobile device160, a new or modified data object is detected and client sync agent 164calls the ClientRecordChanged function in order to pass the new email toclient interface for mobile device 246.

At this point, according to an embodiment, client interface for mobiledevice 246 will look into its local ID map to determine if it hasalready synchronized this particular data object to the server. Theclient interface for mobile device 246 will then use a call to invokethe UpdateRecord method in sync engine object 124. If the clientinterface for mobile device 246 determines that there is no existingrecord ID mapping in its ID map, it will use an empty RecordId in thecall to UpdateRecord.

Client sync agent proxy 366 also represents the proxy object used toreach the server sync agent 128 that is running on a server such asemail server 126. At this point, client sync agent proxy 366 initiatesAsyncMethodInvocation call to the interface for server 348. Thisfunction call is asynchronous and guaranteed to succeed, so at thispoint sync engine object 124 returns from the ServerRecordChangedfunction call.

When sync engine object 124 receives the call to UpdateRecord, it willinsert the data object into its server email database or PIM data store,such as email database 340 and PIM data store 342 depicted in FIG. 3.After the data object is inserted, sync engine object 124 knows the realRecordID that was used for the new email so that client interface forserver 348 can return the new RecordId for the output ID argument in theUpdateRecord results returned to client sync agent 164.

Once client sync agent 164 has the results and the new RecordID thatemail server 126 actually used, it can update the mapping in its localID map so that mobile device 160 knows the device local uniqueidentifier (LUID) in case the data object later needs to be updated ordeleted. Once client sync agent 164 has processed the results of thisUpdateRecord call, it informs server sync agent 128 that it has finishedprocessing the Asynchronous results from the previous UpdateRecord callvia an UpdateRecord(finished) call so that synchronization server 122can clean up by removing the data from the Results Cache.

As synchronization system 300 depicted in FIG. 3 supports prioritizingasynchronous messages, sync engine object 124 will prioritize itemsaccording to data store type (email have priority over tasks in anembodiment) and according to operation type (e.g., insert, update, ordelete). If a data object is date-based (such as an email message orcalendar entry), it will also prioritize based on how ‘current’ thetimestamp of the data object is. For example, in accordance with anembodiment, email messages, applications, business widgets, and calendarentries received today will be synchronized and will be delivered soonerthan items that were received prior to today.

IV. Data Object Identification Handling

In accordance with an embodiment of the present invention, the syncengine object on the synchronization server maintains a table in adatabase or data store that contains mapping information used tocorrelate which unique record identifiers (RecordIDs) from a givenserver sync agent on an email server correspond to which recordidentifiers in a given client sync agent on a mobile device that isbeing synchronized with the email server.

With reference to the embodiment depicted in FIG. 3, sync engine object124 maintains a table in database 314 that contains information aboutwhich RecordIDs from server sync agent 128 on email server 126correspond or map to which RecordIDs in client sync agent 164 on mobiledevice 160. In order to reduce the amount of extra data that is neededto be kept in databases or data stores on mobile device 160 and in emaildatabase 340 or PIM data store 342 on email server 126, sync engineobject 124 is responsible for maintaining the mapping between RecordIDsfrom email server 126 and mobile device 160.

In an embodiment, the ID mapping table is defined as depicted inTable 1. According to an embodiment, the ID mapping table may be arelational database table. In another embodiment, the ID table may be ina data store accessible by the sync engine object.

TABLE 1 ID Mapping Table Columns ServerLUID ClientLUID DatastoreType

When a new data object is being synchronized between a server and amobile device, a new row is inserted into the ID mapping table with atemporary ID entered in the appropriate ServerLUID or ClientLUID columnbased on where the insert came from. After the data object has beensuccessfully inserted and the sync engine object has the results of theinsert (including the actual record ID), the sync engine object willreplace the temporary ID with the actual ID.

When the sync engine object is notified of a modified data object, itwill look up the ID in the ID mapping table. If the sync engine objectfinds a match, then it looks up the matching ID for the given clientsync agent and forwards the update using the appropriate local uniqueidentifier (LUID). If the LUID changes after the update has occurred,the sync engine object will know about the new ID in the results of themethod call. From here, the sync engine object can update the LUID inthe ID mapping table. After a delete has successfully executed on theappropriate client sync agent, the sync engine object will remove therow from the ID mapping table.

A potential problem with the approach described above is that due to theasynchronous nature of the synchronization process, it is possible forthe client sync agent to report a new data object followed shortlyafterwards by a modification or update of the same data object. If thisoccurs shortly before the mobile device goes off-line or the device istemporarily disconnected from the network, the sync engine object willnot yet know the actual LUID that was used for the data object since thesync engine object only has the temporary ID stored in the ID mappingtable. A similar problem can happen in cases where two consecutivemodifications or updates in a row occur and the first modificationchanges the LUID of the data object. The solution to this potentialproblem is described below.

To resolve the asynchronous new data object and consecutive updateproblem, the sync engine object uses a slightly different table to keeptrack of the temporary IDs and/or records that are currently in theprocess of being handled through asynchronous function calls. Ratherthan putting the temporary ID in the ClientLUID column of the ID mappingtable as described above, the sync engine object inserts a new row intoa second table that contains all outstanding synchronization requests.Only once the asynchronous call completes, the sync engine object willupdate its ID mapping table. If the sync engine object receives a secondupdate, modification, or delete request from a client sync agent whenthe first operation is still in the process of being handled, it willqueue an appropriate request to the other client sync agent to act onthe data, but it will send the request as ‘Paused’ to the sync engineobject. Queued requests that are paused are never sent to the clientinterface on the mobile device and/or the client interface on serversuntil they are resumed. Then on the sync engine object callback from thefirst request, the sync engine object will look through the second tablefor any additional queued requests for the same ServerLUID orDeviceLUID. If the IDs have not changed, it will simply resume the nextrequest. If either ID has changed, the sync engine object will cancelthe original request and re-submit it using the new IDs based on theprevious change. According to an embodiment of the synchronizationsystem, the sync engine object will change the function parameters andresume rather than canceling and resubmitting the request.

There exists a potential for timing problems when multiple, simultaneouschanges are made to a data object wherein one of the changes is made ona mobile device that is offline (i.e., completely disconnected from thewireless network). For example, when an email message or calendar entryis composed, edited, or deleted on a mobile device that is not connectedto the network and a simultaneous change occurs on the enterprise emailserver to the same message or calendar entry, there is potential for asynchronization conflict. Similarly, if two instances or copies of anapplication are being executed simultaneously on an enterpriseapplication serve and on a disconnected mobile device, there is asynchronization timing problem associated with synchronizing theapplication data. Lastly, if a business process event is processed on adisconnected mobile device and a corresponding business process event iscompleted on an enterprise application server, a synchronizationconflict arises when the mobile device reconnects to the network.Section VI below describes how these potential timing problems areaddressed in accordance with embodiments of the present invention.

V. Event-Based Synchronization

FIG. 9 illustrates the architecture of event-based synchronizationsystem 900, in accordance with an embodiment of the present invention.FIG. 9 is described with continued reference to the embodimentsillustrated in FIGS. 1-8. However, FIG. 9 is not limited to thoseembodiments.

In an embodiment, event-based synchronization system 900 achievesevent-based synchronization of email/enterprise server 126 and mobiledevice 160 by re-creating events 958 instead of comparing actualdatabase records or fields. According to an embodiment of the presentinvention, events 958 include, but are not limited to applicationevents, and PIM events such as calendar events and email events. Mobileoffice listener 944 detects and tracks events 958 that occur on one ormore data source sites, such as mobile device 160 and anemail/enterprise server 126, and recreates events 958 on the targetsystem, thus keeping events 958 synchronized between email/enterpriseserver 126 and mobile device 160. Although FIG. 9 depicts a singletarget system and one source system, as will be appreciated by personsskilled in the relevant art(s), system 900 can be used to synchronizeevents 958 between multiple source and target systems. Email/enterpriseserver 126 may comprise a PIM server used to manage and store events958. While this embodiment is described chiefly in terms of event 958synchronization between a source system that is an email/enterpriseserver 126 and a target system that is a mobile devices 160, it isapplicable to other event 958 synchronizations such as a synchronizationfrom a source system comprising a mobile device 160 and a target systemcomprising email/enterprise server 126, as well as more generalsynchronization applications involving a mobile device and a server.

According to an embodiment of the invention, mobile office listener 944tracks events 958 as they occur on mobile device 160 andemail/enterprise server 126. As shown in FIG. 9, events 958 may bereceived by email/enterprise server 126 from multiple users 956 usingrespective mobile devices 160 b. The PIM and email events are receivedat email/enterprise server 126 via connections 954 from mobile devices160 b.

In an embodiment, mobile office listener 944 polls email/enterpriseserver via connections 952 in order to detect the events 958 received atemail/enterprise server 126. Mobile office listener then forwards thedetected PIM and email event data 958 to synchronization server 122 viainterface 232.

In an embodiment of the invention, synchronization server 122 determineswhat actions users 956 have performed based on the events 958 receivedvia interface 232. For example, synchronization server 122 may examinean event 958 to deduce that a user 956 has deleted one or more emailmessages and accepted one or more meeting requests. Synchronizationserver 122 then reads data records corresponding to the deduced events958 and creates packets of information corresponding to the deducedevents 958 and forwards the packets to mobile office server 437. Whilethe embodiment depicted in FIG. 9 shows mobile office server 437 as avirtual machine resident within synchronization server 122, it willbecome apparent to a person skilled in the relevant art(s) that mobileoffice server 437 can be implemented as a separate server machine.

According to an embodiment, mobile office server 437 queues the packetsof information corresponding to events 958 for the target system intoqueues 946. The target system illustrated in the exemplary embodiment ofFIG. 9 is mobile device 160. However, the target system can also beemail/enterprise server 126.

The queued packets are then sent from synchronization server 122 tomobile device 160 via interface 230.

Once received on the target system (mobile device 160 in the exampleembodiment depicted in FIG. 9), the queued packets are read and used to‘replay’ the events 958 on the target using a similar sequence ofoperations 948 that were detected on the source system (email/enterpriseserver 126 in the example embodiment depicted in FIG. 9). Once theevents are replayed on the target system, the events 958 are replicatedbetween the source and target systems and the respective data sourcesare synchronized. System 900 tracks and detects events 958 including,but not limited, receipt of an email message, reading of an emailmessage (i.e., when an email message is flagged or marked as read),forwarding an email message, creation of a meeting request, acceptanceof a meeting request, creation of a task, receipt of a task reminder,movement of an email message or item to a subfolder, deletion of one ormore email messages, creation of an email subfolder, and deletion of anemail subfolder.

In another embodiment of the invention, performance of system 900 can beoptimized by examining, with the mobile office server, the chronology ofpackets in queues 946 to determine if older events 958 do not need to berecreated on the target system based on subsequent events. For example,if a packet in queue 946 represents an activity to mark an email messageas read and then subsequently delete the email message, the packetrepresenting the read activity may be deleted from queue 946 as only thedelete activity needs to be sent to the target system in order to playback the most-recent event on the target system. In this way, events 958that are irrelevant or redundant will not be sent to the target systemvia interface 230, thereby reducing the number of operations 948 to bereplayed on the target system.

VI. Synchronization Conflict Handling

According to an embodiment, each call to the UpdateRecord orInsertRecord functions by a client sync agent includes an input/outputparameter called SyncRecordVersion that is passed between the mobiledevice and the server via the synchronization server. This parameterrepresents a unique value associated with a given version of a dataobject being synchronized. In an embodiment, SyncRecordVersion is one ormore of a data object checksum, LastMod timestamp, or a ChangeCounterinteger. After an insert or update operation has finished storing thedata object in a local data store on the mobile device, the client syncagent reads the current data object version from the mobile PIM datastore and includes it in the response results sent back to the syncengine object. The sync engine object then stores this RecordVersion inthe ID mapping table depicted in table 1 above.

According to an embodiment, when subsequent update or delete operationsoccur, the sync engine object will include the previous RecordVersionvalue it had saved in the ID mapping table. For example, when the clientsync agent is processing the update or delete, it will query the currentRecordVersion from the mobile PIM data store.

When there is a no conflict, the client sync agent expects theRecordVersion to still be the same as the previous value. If the currentdata object version does not equal the value sent from thesynchronization server by the sync engine object, then a conflict existsfor the operation.

In an embodiment, when a conflict situation arises, the client syncagent accesses pre-configured synchronization conflict resolution rulesand applies them. According to an embodiment, a copy of the conflictresolution rules are stored in a local data store or database residenton the mobile device. The conflict resolution rules may also be storedand configured on the synchronization server. For example, the conflictresolution rules may be stored in database 314 of synchronization server122. If a conflict rule is configured such that the server wins, and theclient sync agent detected the conflict, the client sync agent willproceed with the update from the server and overwrite the current dataobject (i.e., the server's data object will overwrite the conflictingdata object on the mobile device). For example, consider a case where adata object has already been synchronized between the client and theserver. In this example, the sync engine object contains the informationin the ID mapping table depicted in table 2 below.

TABLE 2 ID Mapping Table After Sync between client and server ServerDatastore ServerLUID RecVer ClientLUID ClientRecVer Type ABCD V001 123V100 Calendar

In an embodiment, if a user on the mobile device subsequently modifiesan email message, business widget, application input, or calendar entryon the mobile device and the server at approximately the same time, thenthe actual server RecVer will now be V002 and the client RecVer will nowbe V200. In this scenario, the sync engine object will not know abouteither one the server RecVer of V002 or the client RecVer of V200 atthis point.

Assume that a client sync agent discovered the change first and reportedit to the sync engine object. The sync engine object will send anUpdateRecord to the client sync via an invocation of the UpdateRecordfunction with the following parameters: Calendar, 123, data, and V100.At this point the sync engine object will have the values depicted intable 3 in its ID mapping table and will have the values listed in table4 in its Queued Request table.

TABLE 3 ID Mapping Table at sync engine object Server DatastoreServerLUID RecVer ClientLUID ClientRecVer Type ABCD V001 123 V100Calendar

TABLE 4 Queued Requests Table at sync engine object Server RequestServerLUID RecVer ClientLUID ClientRecVer DatastoreType ID Status ABCDV002 123 V100 Calendar Reqid1 Active

Now assume that the sync engine object receives another update from theclient sync agent indicating the client change. As the sync engineobject already has a request queued for this particular data object, itwill add another record to its ID mapping table as shown in Table 5 andwill add a corresponding record to its Queued Requests table as shown intable 6.

TABLE 5 ID Mapping Table at sync engine object after client changeServer Datastore ServerLUID RecVer ClientLUID ClientRecVer Type ABCDV001 123 V100 Calendar

TABLE 6 Queued Requests Table at sync engine object after client changeServer Request ServerLUID RecVer ClientLUID ClientRecVer DatastoreTypeID Status ABCD V002 123 V100 Calendar Reqid1 Active ABCD V001 123 V200Calendar Reqid2 Paused

The client sync agent will eventually receive the queued update request.The RecVer sent by the sync engine object was V100, but according to thecurrent state of the actual data, the RecVer is V200. Thus, it is inconflict. Assuming that Server Wins was configured, the clientoverwrites the data object with the current data from the sync engineobject and returns the results.

When the sync engine object processes the results of the client update,it updates the ID mapping table accordingly and resumes thepreviously-paused request. Now the sync engine object ID mapping andQueued Requests tables contain the rows listed in tables 7 and 8,respectively. As shown in tables 7 and 8, the Client RecVer is updatedagain.

TABLE 7 ID Mapping Table at sync engine object after server wins ServerDatastore ServerLUID RecVer ClientLUID ClientRecVer Type ABCD V002 123V300 Calendar

TABLE 8 Queued Requests Table at sync engine object after server winsServer Request ServerLUID RecVer ClientLUID ClientRecVer DatastoreTypeID Status ABCD V001 123 V200 Calendar Reqid2 Active

Now the sync engine object sends server sync agent makes the followingcall to the UpdateRecord function: UpdateRecord(Calendar, ABCD, data,V001). When the server sync agent handles this update request, it checksthe current Record Version and notices that it is actually V002. Sincethe server sync agent knows that the conflict rules configurationdictates that the server wins, the server sync agent will ignore theUpdateRecord call and will return a value or acknowledgment indicatingthat the call was successful but skipped.

As the sync engine object also knows the conflict resolution rules, itcould have also chosen to cancel this request rather than sending italong and marking it as active.

Now the sync engine object ID mapping table contains the record shown inTable 9, the Queued Requests table is empty as shown in Table 10, andthe data object is synchronized on both the mobile device and theserver.

TABLE 9 ID Mapping Table at sync engine object after synchronizationServer Datastore ServerLUID RecVer ClientLUID ClientRecVer Type ABCDV002 123 V300 Calendar

TABLE 10 Empty Queued Requests Table at sync engine object aftersynchronization Server Request ServerLUID RecVer ClientLUID ClientRecVerDatastoreType ID Status

VII. Synchronization Methods

FIG. 10 is a flowchart 1000 illustrating steps by which asynchronization method is used to synchronize communications between amobile device and a back end email or enterprise application server, inaccordance with an embodiment of the present invention.

More particularly, flowchart 1000 illustrates the steps by which thesynchronization of new data object between a mobile client device and aserver is performed, according to an embodiment of the presentinvention. According to an embodiment, the ‘new’ data object can be oneor more of a new, updated, or deleted data object. In an embodiment thenew data object can be one or more of an email message, a web servicerequest, an application, application data, a business process event, acalendar entry, a data file, a data store record, and a database record.The synchronization method synchronizes data objects between a sourcesystem and a target system. As the synchronization method issymmetrical, a mobile client device may be either the source of or thetarget for a data object to be synchronized. Similarly, a server such asan email server or an enterprise application server can be the source ofor the target for a data object to be synchronized. The synchronizationmethod also synchronizes application workflows and business processwidgets between a source system and a target system. According to anembodiment of the present invention, the target and source systems areeither a mobile client device or a server. For example, the target andsource systems can be either a mobile client device or an enterpriseapplication server. Note that the steps in the flowchart do notnecessarily have to occur in the order shown.

The method begins at step 1050 where an evaluation is made regardingwhether a new data object has been created on the source system. In step1050, the creation of the new data object is detected by a listener. Ifit is determined that a new data object on the source system needs to besynchronized, control is passed to step 1052. If it is determined thatno new data object needs to be synchronized, then control is passed tostep 1082 where the method ends.

In step 1052, methods are called to indicate the existence of the newsource system data object to the target system. As the synchronizationmethod is symmetrical, the mobile client device may be either the sourceof or the target for the new data object detected in step 1050.According to an embodiment, the functions include ServerRecordChanged,UpdateRecord, and an asynchronous AsyncMethodInvocation function.

In step 1054 an evaluation is made regarding whether the target involvedin the synchronization is offline. For example, if the target is amobile client device, it may be offline due to being shut down orrebooted by a user. If the target is a server, it may be temporarilyoffline due to a scheduled shutdown (i.e., for scheduled maintenance) oran unscheduled reboot/restart. If it is determined that the target isoffline, control is passed to step 1056. If it is determined that thetarget is online, then control is passed to step 1058.

In step 1056, information needed for the method calls on the target aresaved in the target system's request cache while the target is offline.In an embodiment, control is passed back to step 1054 based upon events(i.e., triggered by events) to determine if the target system is stilloffline. In another embodiment, step 1054 is repeated on-demand and notevent-based. In an alternative embodiment, control is passed back tostep 1054 at a timed interval that is tunable. In another embodiment,the interval varies based on factors including one or more of the numberof method calls queued in the target system's request cache, the type ofmethod calls (i.e., insert, modify, delete) in the cache, thecharacteristics (i.e., memory size, CPU speed, storage capacity, networkconnectivity) of the target system, and other factors.

In step 1058, outstanding asynchronous calls to InsertRecord are made.This step is performed after the target is online. In this step, oncethe target is online and receives a request to make a method call, themethod call is made on the target, the method is executed on the target,and the control is passed to step 1070 where the results of the methodcall will be queued until the target is connected to the source system.Any asynchronous calls queued in the target system's request cache aremade in this step and control is passed to step 1070.

In step 1070, results from the method calls of step 1058 are saved andqueued in the results cache of the target system and control is passedto step 1072.

In step 1072 an evaluation is made regarding whether the target systeminvolved in the synchronization can connect to the source system. Forexample, in this step it is determined whether a target system canconnect to a source system via a wireless network, a wide area network(WAN), the Internet, and/or a corporate network/intranet. If it isdetermined that the target cannot connect to the source system, controlis passed to step 1074. If it is determined that the target system canconnect to the source system, then control is passed to step 1076.

In step 1074, results from the method calls completed in step 1058 arestored in the target system's results cache while the target systemcannot connect to the source system. In an embodiment, control is passedback to step 1072 to determine if the target system is stilldisconnected from the source system. According to embodiments of theinvention, repetitions of the evaluation in step 1072 are on-demand orevent-based. In an alternative embodiment, control is passed back tostep 1072 at tunable, timed intervals. In another embodiment, frequencyof repetition of step 1072 varies based on factors including one or moreof the amount of results stored in the target system's results cache,the type of method call results (i.e., results of data objectinsertions, modifications, or deletions) in the results cache, thecharacteristics (i.e., memory size, CPU speed, storage capacity, networkconnectivity) of the target system, and other factors.

In step 1076, the results of the method call queued in step 1070 aredelivered to the source system and control is passed to step 1078.

In step 1078, an evaluation is made regarding whether the receipt ofresults data delivered in step 1076 have been acknowledged by theserver. If it is determined that the server has acknowledged receipt ofthe results data, control is passed to step 1080. If it is determinedthat the server has not acknowledged receipt of the data, then controlis passed to step 1082 where the method ends.

In step 1080, results are removed from the target system's results cacheand control is passed to step 1082 where the method ends.

FIG. 11 is a flowchart 1100 illustrating steps by which new records aresynchronized between a mobile device and a server such as a back endemail server or an enterprise application server, in accordance with anembodiment of the present invention.

More particularly, flowchart 1100 illustrates the steps by which thesynchronization method for new data objects, including new, updated, anddeleted email messages, calendar entries, data files, and databaserecords, is performed, according to an embodiment of the presentinvention. The synchronization method synchronizes multiple new recordsbetween a source system and a target system. The method also handlescases where a new data object to be synchronized is subsequentlymodified before the synchronization is complete. The synchronizationmethod also synchronizes application workflows and business processwidgets between a source system and a target system. According to anembodiment of the present invention, the target and source systems areeither a mobile client device or an email server. In another embodiment,the target and source systems are either a mobile client device or anenterprise application server. Note that the steps in flowchart 1100 donot necessarily have to occur in the order shown.

The method begins at step 1150 where an evaluation is made regardingwhether a new data object has been created on the source system. In step1150, the creation of the new data object is detected by a listener. Ifit is determined that a new data object on the source system needs to besynchronized, control is passed to step 1127. If it is determined thatno new data object needs to be synchronized, then control is passed tostep 1149 where the method ends.

In step 1127, a temporary record identifier (record ID) for the new dataobject detected in step 1150 is inserted into an ID mapping table.

In step 1129, a sync engine object on a synchronization server isnotified of the new data object detected in step 1150. According to anembodiment, the synchronization server may be one or more computers. Inanother embodiment, the synchronization server may be a virtual machinerunning on the email server. Conversely, the functionality of the emailserver may also be running on the synchronization server. In anotherembodiment, the synchronization server may include a mobile officeserver configured to synchronize application workflows and businessprocess widgets.

In step 1131, the new data object is synchronized onto the target systemby inserting it on the target system, wherein the target system is oneof a mobile client device, an email server, or an enterprise applicationserver.

In step 1133, results are returned to a sync engine object resident on asynchronization server, wherein the results include at least the actualrecord ID from the target system.

The method continues in step 1135 where the ID mapping table used by thesync engine object is updated with the actual record ID from the targetsystem.

In step 1137, an evaluation is made regarding whether a data object hasbeen modified on a source system. If it is determined that a modifieddata object on the source system needs to be synchronized, control ispassed to step 1139. If it is determined that no modified data objectneeds to be synchronized, then control is passed to step 1149 where themethod ends.

In step 1139, an evaluation is made regarding whether the record ID ofthe modified data object matches the corresponding record ID stored inthe sync object engine's ID mapping table. If it is determined that themodified data object's record ID matches the record ID in the ID mappingtable, control is passed to step 1147. If it is determined that themodified data object's record ID does not match the record in the IDmapping table, then control is passed to step 1141.

Step 1147 is further described below.

In step 1141, an evaluation is made regarding whether the new dataobject detected in step 1150 is the same data object whose modificationwas detected in step 1137. If it is determined that the new data objectis being modified, control is passed to step 1143. If it is determinedthat the new data object is not the data object being modified, thencontrol is passed to step 1147.

Step 1147 is further described below.

In step 1143, a new record is inserted into a Queued Requests table anda ‘paused’ request is sent to the sync engine object. According to anembodiment, queued requests that are paused are not sent to a clientinterface on the target system (mobile device, email server, orenterprise application server) until the requests are resumed.

In step 1145, the queued requests are processed. In this step, thequeued requests are identified by querying the Queued Requests tablepopulated in step 1143. In an embodiment, the sync engine objectcompares the local unique IDs (LUIDs) for server records (identified bya ServerLUID column) and mobile device (identified by a DeviceLUIDcolumn) records in the Queued Requests table. If the ServerLUID andDeviceLUID IDs have not changed, the sync engine object will ‘resume’the next request in the Queued Requests table and the request will beprocessed. If either the ServerLUID or DeviceLUID has changed, the syncengine object will cancel the original request and resubmit the requestby passing control to step 1147 using the new LUIDs based on themodification detected in step 1141. In an alternative embodiment, thesync engine object may change the function parameters and resume thequeued request instead of canceling and resubmitting the request.

In step 1147, the data object update for the data object modificationdetected in step 1137 is forwarded to the target system, wherein thetarget system is one of a mobile client device or a server. Theforwarded request includes the LUID for the modified data object. Inthis step, the target system responds to the sync engine object with anacknowledgment indicating that the data object was updated. After thedata object is updated on the target system, the sync engine objectupdates the corresponding LUID in the ID mapping table and control ispassed to step 1149 where the method ends.

VIII. Example Computer System Implementation

Various aspects of the present invention can be implemented by software,firmware, hardware, or a combination thereof. FIG. 12 illustrates anexample computer system 1200 in which the present invention, or portionsthereof, can be implemented as computer-readable code. For example, themethods illustrated by the flowcharts 1000 and 1100 of FIGS. 10 and 11can be implemented in system 1200. Event-based synchronization system900 can also be implemented in system 1200. Various embodiments of theinvention are described in terms of this example computer system 1200.After reading this description, it will become apparent to a personskilled in the relevant art how to implement the invention using othercomputer systems and/or computer architectures.

Computer system 1200 includes one or more processors, such as processor1204. Processor 1204 can be a special purpose or a general purposeprocessor. Processor 1204 is connected to a communication infrastructure1206 (for example, a bus, or network).

Computer system 1200 also includes a main memory 1208, preferably randomaccess memory (RAM), and may also include a secondary memory 1210.Secondary memory 1210 may include, for example, a hard disk drive 1212,a removable storage drive 1214, flash memory, a memory stick, and/or anysimilar non-volatile storage mechanism. Removable storage drive 1214 maycomprise a floppy disk drive, a magnetic tape drive, an optical diskdrive, a flash memory, or the like. The removable storage drive 1214reads from and/or writes to a removable storage unit 1218 in a wellknown manner. Removable storage unit 1218 may comprise a floppy disk,magnetic tape, optical disk, etc. which is read by and written to byremovable storage drive 1214. As will be appreciated by persons skilledin the relevant art(s), removable storage unit 1218 includes a computerusable storage medium having stored therein computer software and/ordata.

In alternative implementations, secondary memory 1210 may include othersimilar means for allowing computer programs or other instructions to beloaded into computer system 1200. Such means may include, for example, aremovable storage unit 1222 and an interface 1220. Examples of suchmeans may include a program cartridge and cartridge interface (such asthat found in video game devices), a removable memory chip (such as anEPROM, or PROM) and associated socket, and other removable storage units1222 and interfaces 1220 which allow software and data to be transferredfrom the removable storage unit 1222 to computer system 1200.

Computer system 1200 may also include a communications interface 1224.Communications interface 1224 allows software and data to be transferredbetween computer system 1200 and external devices. Communicationsinterface 1224 may include a modem, a network interface (such as anEthernet card), a communications port, a PCMCIA slot and card, or thelike. Software and data transferred via communications interface 1224are in the form of signals which may be electronic, electromagnetic,optical, or other signals capable of being received by communicationsinterface 1224. These signals are provided to communications interface1224 via a communications path 1226. Communications path 1226 carriessignals and may be implemented using wire or cable, fiber optics, aphone line, a cellular phone link, an RF link or other communicationschannels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage unit 1218, removable storage unit 1222, and a hard diskinstalled in hard disk drive 1212. Signals carried over communicationspath 1226 can also embody the logic described herein. Computer programmedium and computer usable medium can also refer to memories, such asmain memory 1208 and secondary memory 1210, which can be memorysemiconductors (e.g. DRAMs, etc.). These computer program products aremeans for providing software to computer system 1200.

Computer programs (also called computer control logic) are stored inmain memory 1208 and/or secondary memory 1210. Computer programs mayalso be received via communications interface 1224. Such computerprograms, when executed, enable computer system 1200 to implement thepresent invention as discussed herein. In particular, the computerprograms, when executed, enable processor 1204 to implement theprocesses of the present invention, such as the steps in the methodsillustrated by flowcharts 1000 of FIGS. 10 and 1100 of FIG. 11 discussedabove. Accordingly, such computer programs represent controllers of thecomputer system 1200. Where the invention is implemented using software,the software may be stored in a computer program product and loaded intocomputer system 1200 using removable storage drive 1214, interface 1220,hard drive 1212, or communications interface 1224.

The invention is also directed to computer program products comprisingsoftware stored on any computer useable medium. Such software, whenexecuted in one or more data processing device, causes a data processingdevice(s) to operate as described herein. Embodiments of the inventionemploy any computer useable or readable medium, known now or in thefuture. Examples of computer useable mediums include, but are notlimited to, primary storage devices (e.g., any type of random accessmemory), secondary storage devices (e.g., hard drives, floppy disks, CDROMS, ZIP disks, tapes, magnetic storage devices, optical storagedevices, MEMS, nanotechnological storage device, etc.), andcommunication mediums (e.g., wired and wireless communications networks,local area networks, wide area networks, intranets, etc.).

IX. Conclusion

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be understood by those skilledin the relevant art(s) that various changes in form and details may bemade therein without departing from the spirit and scope of theinvention as defined in the appended claims. It should be understoodthat the invention is not limited to these examples. The invention isapplicable to any elements operating as described herein. Accordingly,the breadth and scope of the present invention should not be limited byany of the above-described exemplary embodiments, but should be definedonly in accordance with the following claims and their equivalents.

What is claimed is:
 1. A method for synchronizing events between amobile device and a server, the method comprising: detecting an event tobe synchronized between the mobile device and the server; deducingactivities that occurred in order to create the detected event; readingdata records corresponding to the deduced activities; creating packetsof operations and data records needed to recreate the deduced activitieson the server; queuing the packets of operations and the data records ifit is determined that the mobile device is offline; repeating thequeuing until it is determined that the mobile device is online; andobtaining event synchronization results after the queued packets ofoperations have successfully executed on the server, wherein the eventsynchronization results include at least a synchronization status and aunique record identifier identifying the event.